技术干货 | D2前端技术大会经历漫谈

编者按：第14届D2前端技术大会，通过6大主题，21场精彩分享，勾勒未来前端的主战场，未来的前端挑战与机遇。作者结合当天的交流，与NodeX Node.js生态体系在滴滴的打造实践，分享了自己的思考和收获。在文章后半部分，我们还特意增加了更多同学的精彩分享，欢迎赏阅。

1.

相关资料

● 第14届由阿里经济体前端委员会主办的面向全球前端领域的技术论坛，本届主题

智能化专场 | Serverless专场 | 工程化专场

微前端专场 | 语言框架专场 | 多样化领域专场

  ● 活动主页

http://d2forum.alibaba-inc.com/

● 嘉宾PPT-更新中:

https://github.com/d2forum/14th/tree/master/PPT

2.

来到会场

好多展示台，有比如菜鸟智能化搭建、蚂蚁花呗3D模型到运营活动搭建，蚂蚁AntV数据可视化，会场大屏配置实时搭建 ，还有掘金、SegmentFault 等平台，在现场通过台位具体的活动、演示来吸引开发者关注他们的项目。

3.

展台交流 - 

3D模型到运营活动搭建

与蚂蚁花呗/借呗3D模型到运营活动搭建展台进行了交流。在日志业务场景中，有大量的营销或者交互小游戏，之前他们需要设计师给出一帧帧的图片 或者Gif, 或者需要前端同学通过css动画、canvas一句句实现，会面对生成效率低、可控性低，或者是达不到设计师实现要的效果。且在大量二维普通活动游戏后，用户较为麻木，活动效果不明显。他们通过WebGL 制作3D可交互动画来促进用户参与感，因为越来越多这样的需求，为了促进批量化生成，他们沉淀了如下一套方案：

● 平台沉淀模型 + 皮肤材质

● 业务设计师出3D模型+ 素材

● 开发者可视化IDE编辑模型、添加js 脚本控制交互

● 导出平台3D动画模型 + 端上+浏览器引入平台提供的WebGL 渲染Runtime

逼真的、可交互的3D动画就这样快速实现了 。他进而给我们展示他们六、七个由此开发的营销活动。我们日常玩的蚂蚁庄园小鸡一个个3D游戏交互就是这么实现的。

明年上半年，他们将会将这个平台的Runtime开源出来，并提供3D模型编辑配置、交互脚本编写调试平台(未有开源计划)，供大家使用。

感想是，本届活动虽然没有关于3D Web相关的分享，但随着网络、性能提高，未来图像视觉可视化将是前端一个主战场。

他们通过技术驱动将活动从2D 带入 3D, 大大提高用户的参与度，促进业务发展，并沉淀平台，量产化，记忆深刻。

4.

圆心开场致辞

大佬开场总起了大会的几个方向，以及未来前端的主战场，未来的前端挑战与机遇并存。

▌ 端侧渲染体系的重塑

从PC时代到无线时代，再到未来的IOT时代，在渲染方面诞生了很多优秀的技术，RN、Weex、Flutter、小程序体系等。基于底层的渲染思路，Native的渲染，2D、3D性能体系，包括WASM集成到无线端来渲染， 都带来了很多可能性。

▌ 2B中后台场景垂直领域的深度沉淀

从2C场景到2B场景，以前由大量外包全栈支撑的中后台体系也在变为专业前端的主战场。中后台领域有框架、布局、组件、数据交换，庞大体系的运作（跨团队协作）等各种挑战，在技术上也有可视化、Web Excel、编辑器、搭建、智能化等各种方向值得深入。不同域的体系下如何和后端体系打通，领域模型的贯穿等，都是需要探索与沉淀的。

▌ 从传统开发模式到云+端开发模式

云使业务体系平台化，接口化，在端侧效率化，业务化。前端关注到从页面到业务。Serverless一定是未来趋势，前端能力必须匹配未来技术要求。

▌ 前端智能化

页面的构成，结构，标准化。这一块淘系的 imgcook 已经做得很不错了，在今年的双十一也有智能代码生成的大规模落地。

▌ 语言底层的深入

国内的语言与国际接轨，需要从底层做起，参与标准化的制定，促进JS语言的发展。最近贺老也加入了TC39，希望以后在标准化的制定上，能看到越来越多国人的身影。希望国人，当现有东西不能支持，不好用的时候，有更深的思考，从底层，用语言层面解决问题，而不是仅仅在上层封装适配。

5.

Tensorflow.js 

前端的机器学习平台

未来是智能化的战场，故第一场选了这场。来自google 的工程师，Tensorflow.js 核心开发者带来的这场分享记忆深刻。他的表达、PPT形式、现场的互动，我认为都很不错。有入门介绍、有演示demo、有代码demo、有整体流程，给我自己在日常的分享，带来不少经验和提醒。总之听完后，给你的感觉机器学习，在端上、浏览器上用Tensorflow.js 实现一个功能这么简单，大大提高了大家的兴趣。总结如下：

● Tensorflow.js 已经生产环境 ready。

● 有端上版本、服务端版本，主流浏览器、小程序等都兼容。

● 性能较高，开启WebGL 加速，Web上20-50ms 一帧的渲染，能达到较为流畅的视频帧率。具体可以通过选择不同模型精度的来提高性能。他展示了雅诗兰黛(品牌可能不对)口红，通过人脸识别嘴巴，用户在小程序中，选择不同口红的颜色，实时渲染用户使用该颜色的效果，大大促进了用户的转化率，整体实现的效果很不错，很流畅。

我们可以找到一个场景，通过如下流程将Tensorflow.js 使用起来。

● 产生模型，通过大量数据跑出一个模型，或者用开源的模型(手势、人脸、人体部位、图片识别)，这往往可以让公司专业机器学习团队实现，提供模型。

● 转化模型面向Tensorflow.js ，我们通过 Tensorflow.js 提供的CLI 命令将模型进行一次的特定化转化。

● 加载模型，在端上、浏览器中，加载转化后的模型，大概2-3句代码。

● 采集的内容喂给模型，在端上、浏览器中，开启语言、视频、文件等其他采集设备，将采集的内容喂给模型，大概2句代码。

● 通用结果 Tensorflow.js 对于视频、图片可以返回处理好的视频、图片，如人体识别后的背景的虚化、人体部位识别后大长腿处理，图片内容识别后，进行框框的实时标注。

● 个性化处理结果 Tensorflow.js 也可以将实时结果通过一个ArrayList返回，如告知识别图片内容的框框位置、高度宽度、可信度等返回，业务拿到数据可以自己个性化处理交互显示。

对我们的意义，基于集团的海量数据提供的机器学习的模型，在端上和Web端找到场景，大胆的去尝试。

6.

标准微前端架构

在蚂蚁的落地实践

微前端内核乾坤项目：https://github.com/umijs/qiankun 对应的分享来自蚂蚁。结合他们自2018-年底开始，基于微前端架构模式，探索出了一套完整的一体化解决方案，无痛的将原有的大量页面迁移成微前端架构，最复杂的他举例了阿里云应用中，集成来自15个部门的页面。我总结下他们的方案，这块对于我们现在通过NodeX Serverless页面及服务，通过iframe搭建统一工作台, 无痛迁移至微前端架构，解决iframe交互痛点与性能问题是一个很有借鉴意义的一个方案。

"与页面技术无关，接入友好 "是他一直很强调的微前端关键点。因为要保证不同技术栈、不同开发构建、历史大量页面能无痛的、自由的集成入微前端体系。方案总结如下：

● 提供一个Runtime, 这个是个站点的主运行代码，Runtime的职责如下： 

a. 提供通用菜单、导航。

b. 处理路由，并更加路由加载对应的集成入的页面，该页面通过一个enter 为 .html 入口来配置。

c. 处理动态加载页面的的生命周期，加载动态页面、提取传入动态页面，卸载动态页面，清理环境让环境变为最初状态。

d. 处理页面间通信，通信必须通过Runtime，不能自定义通信，只记住了这样要挨打，具体有啥影响不知道了。

● 当用户点击一个菜单一个页面是，Runmtime路由加载整个html 页面，并将整个页面完整的插入页面节点中，可以理解，还是原来iframe方式，只是移除iframe, 将内容整体移出来到父层，现在是同层。

● 当用户又点击菜单，执行约定的之前加载页面的生命周期 unmount 函数，将其“污染”的DOM, “污染”的样式移除、“污染”的全局对象移除, “污染”的事件监听移除，一切变成最初干净的样子。这里涉及到一些技术、样式隔离、全局对象proxy、diff 等能力。

● 加载新页面，执行前面过程，每个页面有对应周期bootstrap -> mount -> unmount

这就完成了，对 SPA、MPA、技术栈无关、低迁移成本等微前端应用。

7.

微前端沙盒体系

来自字节跳动前端开发者的一个分享，因为隔离是实现微服务的最为核心技术，对这个分享还是抱着满满期待。讲师的分享讲得比较偏向细节，但缺少一张整体的沙盒体系整体图，或是对应核心代码对象使用的展示。对服务端nodejs 隔离方案还是有一定理解的我，最后还是大部分时间云里雾里的。

整体分享里对他这个不错的类比还是记忆深刻的：

● 虚拟机 == iframe

● docker == 微前端沙箱

还有个进行环境清理的 Diff 算法，从笛卡尔复杂度到0(n) 每个比较增量的复杂度，有些记忆，具体就不理解了。

8.

前端工程下一站：IDE

来自阿里巴巴和蚂蚁对 IDE 这个领域的分享。支付宝小程序IDE等集团对内、对外产品中的IDE是通过他们提供的能力搭建的。总结如下：

● 列举了社区开源IDE方案，如NodeX现在用的方案。

● 借鉴社区，他们从零设计方案，搭建面向集团各个部门有IDE需求的通用IDE服务与生态。

● 该方案在设计开发中移除NodeJs特定的依赖，从而做到 electron 桌面IDE应用 + Web IDE 的兼容。目前还处于桌面IDE阶段，Web IDE在路上了。

● 他们将IDE 背后设计的各种服务，面向业务团队特定部署，来做到隔离、容灾、成本等核算。

● 他们设计了一套面向公司内部的插件规范，这套插件规范与vscode 插件规范比起来，可高度定制化，这也是为什么他们自己从零打造IDE的原因之一，VScode插件他们也做到了兼容，但反之不兼容。

● 同样是明年上半年他们计划会将这个IDE 的方案开源出来，供社区参考。

对我们的意义，在目前我们NodeXWebIDE定制化不高，可以先用社区方案，快速跑起来。未来无论是滴滴内部IDE服务化通用化接入，还是使用它们可高定制IDE开源方案搭建，还是使用现有开源方案源码级修改达到高定制，都需要我们在IDE 这块有更专业的理解。

9.

前端新思路：

组件即函数和Serverless SSR 实践

这个来自 阿里巴巴 狼叔 关于利用Serverless Faas 能力进行 SSR 渲染实践的分享。总结如下：

● Faas SSR，他们的出发点是让前端不再需要深度理解Egg、Webpack , 便捷大家SSR服务，通过SSR，大大加快首屏渲染。

● 他们的实践方案是，同构端渲染和服务端渲染，页面即服务 => 组件即服务 => 函数即组件。同构方案，让这个React 组件，即能通过 Faas 函数渲染出一个页面，也支持通过BigPipe 技术，通过静态资源方式 + 动态数据流输出，在前端端上进行渲染。并且这两个方式可以根据场景进行结合、还可做到容灾处理。

● 问了狼叔关于Serverless Faas能力的搭建问题，狼叔表示他们还不关心这层，目前管用就好，表示十分羡慕。这同样也让我们更加明确，这层能力终将下沉到集团基础能力，供各个业务团队使用，探索上层使用场景。我们最好推动滴滴搭建这样的平台。但在这个过程中，只有更熟悉下层的能力、前期才能推进这个东西，后期才能充分发挥下层能力，搭建面向前端的上层能力。

在线下交流，还询问了狼叔通过Faas 渲染页面，页面独立零散，如何进行管理，有没有考虑合并页面到一个工程中来渲染。狼叔说这个Faas 带来的问题，刚才分享只讲了它的好处。后面那位分享在做一个多个Faas 聚合的事，可以听下。

又交流到egg, 我谈到egg 的进程管理目前使用不习惯 。

● 进程服务状态查看

● 没有热部署 

● 没有内存大小限制兜底

狼叔分享到egg 可以只用egg-core 不使用 egg-scripts 启动，仍用pm2 管理，就可以解决。这个对我们十分有意义，这样我们不仅能保留pm2 的能力，还能在由egg打造面向滴滴内部框架Degg上，继续保留我们nodex-monitor 结合pm2 对node 进程结合公司odin平台进行监控、报警。

最后SSR 这块，将通过应用聚合faas来解决 上面那个faas SSR 页面零散的问题，这也正是我们采用的方案。对NodeXServerless SSR 有了更好的期待。

10.

Serverless 下函数应用架构升级

这个分享者来自阿里巴巴 midway团队，分享内容是和我们在做的事最接近的一个分享。他团队做的是上面狼叔SSR的底层，即提供Faas 给狼叔使用的平台方。但他们也是中间层，将业务层的serverless 配置+代码 部署到公司Serverless平台，总结如下。

他们在做一件和开源Serverless框架类似的事，屏蔽底层不同平台Serverless 不同的规范如：

● serverless yaml 配置文件不同

● serverless Faas 上下文 入口函数参数不同

背景是阿里巴巴集团内部，因为事业部众多，包括阿里云在内, 有3个搭建和提供了ServerlessFaas 能力, 故他们在做这层适配抽象，让Faas 这层配置更简单、能快速无缝迁移部署到多个平台。既然做了这件事，他们干脆和Serverless开源方案一样，把腾讯云、AWS等其他平台Serverless 规范也兼容了。

面对如同狼叔 Faas SSR 以函数粒度拆分粒度太细，导致的管理不便。他们做了一层抽象，提供Runtime, 在这个Runtime 里进一步做从Serverless 网关打过来的路由，将流量路由到这个应用里多个Faas。并提供了 yaml 中个性化定义的聚合配置属性 aggregation，将多个faas函数聚合成一个路由，暴露给底层Serverless平台。

这里有个关键，Faas 聚合成应用正是我们NodeX Serverless方案要的，通过线下交流，告知了底层Serverless平台, yaml 配置支持如下serverless.yaml 配置路由：/appA/* ，

此时appA 应用流量就会打入到他们提供的Runtmime, 这个Runtime 里的egg 路由会将 流量转发给 如狼叔分享里的一个个 faas 函数中，这个方案和我们一致。

可以得出的结论是，基于弹性云搭建的Knative平台，通过一个特定yaml 配置，对应路由 / appA/* 打到我们Runtime 就能做到我们的期望（应用级隔离，应用级管理Faas，Faas资源利用率提高，动态发布页面），并且平台本身就支持这种能力，不需要为了我们方案做个性化处理。 

另外，在下面两个点也给我们也带来了启示：

● 通过 typescript interface 导出 Runtime context 上下文，方便开发者写业务逻辑时，知道上下文有哪些对象，如何使用。

● 通过typescript 结合注解，可以将原本割裂的配置，亦或者现在NodeX采用标签属性配置的方式，进一步更直观、自然地与业务代码共存。

11.

基于 wasm 的H265播放器

及在 NOW 直播中的应用

因为最近了解了webassembly标准化和它的潜力，以及面对未来网络环境下视频等也必将是前端一个主战场，故去听了这场来自腾讯IVWEB小哥哥的分享，整个分享也是很幽默。

总结如下：

● 直播等视频领域，视频的编码、解码的效率、流的压缩程度这些核心技术，能大大提高相同带宽下视频的质量。一个不好的压缩，和一个优秀的压缩编码，他们流量的大小差别100倍以上，对于公司、对于用户都是妥妥的钱呀。

● 对于视频流的压缩算法，是一个多个标准共存的状态，这里面又是个大厂利益争夺的地方。公司需要交特定压缩算法的钱，这个钱对YouTub 这样量级公司一年是上亿美金。故通过使用对公司专利授予友好，钱少交，还能达到不错效果的方案，就显得十分重要。

● 整个分享讲Webassembl内容不是很多，主要是了解到webassembly 的can I use 兼容性已经不错了。通过webassembly提供的能力，我们可以直接使用 C/C++、Rust、Go等现有优秀的算法，通过webassembly编译工具直接编译成wasm 二进制字节码文件， 在浏览器js、或者服务端nodejs, 直接高效运行。比之前我们了解到要写nodejs c++ 插件，需要通过Nodejs N-API 自己写一些C++代码，做一层胶水层来封装。webassembly 就方便了，更重要的是它支持多种语言，性能也佳。

● 还分析了直播视频播放的技术架构，从端的视频数据采集，视频、音频编码压缩，实现视频音频流媒体，切片的发送到云端，然后推送到用户的一端，在进入流媒体的解压，再到视频、音频的解压，这个过程或加入特定filter图像算法，大长腿、磨皮就在这里，然后形成播放器可识别播放的媒体文件，进行播放。

a. 方案涉及到视频、音频的对齐，由于人对音频更为敏感，故视频服从于音频对齐。

b. 方案还涉及到观看体验的优化，会对视频音频流进行缓存处理。

● 还讲了H265 对比 H264视频编码原理的区别，这里对视频压缩有了一定了解：其本质就是把视频里的每一帧图片，切成一块块方块，进行块之间对比分析，这个时候一大片黑色就只要传输一个块就行，与黑色块距离近的灰色块也只要传输颜色差异描述就行，一帧帧前后也进行这样的分析，让视频压缩传输的尽量小，又能复原成高保真原始视频。

12.

总结

以上是我上周参加D2的一些体会和感受，肯定有理解不全，理解不对的地方，多多包涵。

更多分享的PPT逐步新鲜出炉，我们可以更深入重温分享内容，细细咀嚼。

短短45分钟的分享，涵盖这一个分享者、一个团队、甚至是一个公司在一个领域内的长时间实践总结。肯定是不能一下get 到全部点的，但给予我们的方向指导意义更大。在我们实践过程中，一定会对其中之前没能理解的内容，有不同的感悟，有更好的帮助，另外：

● 只有掌握核心技术，才能更好的技术驱动业务。

● 保持对NodeX所做事情的自信，不妄自尊大，不妄自菲薄。

● 多了解技术发展，多交流，闭门造车，不可取，站在巨人肩膀上，他山之石可以攻玉。

13.

来自更多同学的分享

【 卢群 】

对于D2大会分享的收获

1.《云生态新物种-微前端框架体系》克军

克军分享的“微前端框架体系”是非常有体系性的，从微前端的概念，以及微前端的体系架构都做了完整的介绍，对我们的借鉴意义非常大。

“微前端不是一个框架/工具，而是一套架构体系”，从概念上，克军告诉我们，微前端不单单是某一个框架就能够承载的，微前端是一套完整的体系，这个体系你可以做得很大很完整，以至于几乎所有的产品都可以通过这套体系构建成一个完整的平台服务。

所以，实践微前端方案，有以下几点需要做：

1）根据现有架构设计适合我们自己的架构体系

在克军分享的体系中，拥有“配置中心”、“观察工具”、“微应用市场”和“微应用容器”，以及和Serverless的密切配合，构建成完整的生态体系。

 这套体系里面，有些内容我们现在就能够直接支持，比如“配置中心”就可以利用upm的能力来管理应用，Serverless服务体系我们也在逐渐完善起来，我们要做的是梳理清楚我们自己想要一个什么样的微前端架构，设计完整的方案并逐步落地。

 2）克服实践中的困难

方案有了，接下来就是要落地方案。鉴于我们之前都没有这方面的经验，我们就不可避免需要趟一些坑。也许，我们需要在不断解决困难和问题的过程中搭建起我们自己的微前端框架来。

2.《标准微前端在蚂蚁的落地实践》有知

有知的分享也提供了很多干货的内容，其中在微前端的方案细节上就提供了很多可以学习借鉴的地方，比如：

● 基于生命周期的微应用管理模式

● 微应用之间必须要充分解耦

● HTML Entry的方案比Config Entry的方案更好

● CSS隔离推荐用CSS Module

● Web Compennets不首先推荐，会遇到一些坑

● 用JS沙盒进行环境隔离

● 公共依赖加载的解决方案

同时，有知分享的OneTour组件也非常有借鉴意义，这个有点类似现在我们普惠业务工作台的工作流能力，能够将某一个产品的操作流程做成一个文档，用户可以边看文档边操作功能，大大提升用户的功能使用体验。

3.《微前端沙盒体系》艾石光

艾石光分享的微前端沙盒体系，是对该微前端体系的更加深入的实践。整体来说，艾石光的分析更多的是偏于理论方面，并没有太多的代码和流程示意，对于我来说接受度不是特别高，吸收的程度也稍微低一些。但好在这些理论能够记录下来，在后期我们对微前端沙盒进行深入研究和开发的过程中会提供一些参考。

为什么说D2大会的现场更好呢？

1、获得先机

为什么有些人愿意花大价钱买新版的iphone手机？为什么有人愿意抢票看半夜新上映的电影？因为你有了最新款的iphone就会吸引更多人的目光，你看了最新上映的电影你就可以和朋友有更好的谈资。

参加D2大会现场也是如此，你能够第一时间获取前端领域最新的成果和方向，你就是占据了先机。

一流的团队会不断探索和主动发展领域技术，二流的团队是待有新的技术成果立马跟上，三流的团队是享用其他人的劳动成果。

 终身学习的目的就是让自己领先同辈人一步，以便成为具有时效性的人才，避免在低水平上竞争。

不管是团队，还是个人，如果懂得抢占先机，才能够有机会把握未来。

2、内化不同

看PPT不如看视频，看视频不如到现场听嘉宾分享。如果给你一个PPT你就能够获取大部分的信息，并消化成为自己的东西，那嘉宾也就不需要亲自来做分享了。

文字内容的背后，往往包含了更多丰富的内容，而价值最大的内容也就在这些背后的内容里面。所以，如果不参加D2大会现场的分享，可以说D2的所有内容对于你来说价值并不大。

 【 张哲 】

全天听下来，克军的微前端分享给我的感触比较深，除了讲述他对微前端的思考，还有很多他对前端架构的理解。 

什么是前端架构？之前我们可能会说做做技术选型，工程化，做个跨端的框架等等。但是架构并不只是这些，架构的目的是建立能解决自己业务问题的技术体系，不能看别人做什么你就要做什么，一定要深入去看自己的业务场景。

什么是微前端？微前端就像微服务，并不是一个框架就可以解决的，而是一套用以治理大型Web应用的架构体系，就像微服务需要rpc、服务发现、注册、负载、熔断等等，微前端也需要类似版本管理、发布策略、动态构建、沙盒、隔离等等周边内容，用以治理我们的Web页面。

克军在这里提到一个观点很棒：做技术架构，不能只看技术价值，技术价值只是面向技术团队的，技术架构一定要为业务带来价值， 同时，他也提到了微前端的业务价值：

● 产品原子化：因为每个应用独立，扩展性、组合性大大提升，可以快速进行局部迭代。 

● 解决能力输出“最后一公里”的问题，比如A业务想把一个能力输出给B业务，以往只能以页面跳转或者Iframe的方式嵌入，如果有了微前端的架构，就可以让B业务快速接入。

● 云生态中的新物种，微应用：即由微前端+微服务提供一个独立的应用 。然后，我发现我们这里的两个问题，就很适合以微前端的思路来解决：

a. 比如桔研和星云，问卷搭建、列表、数据分析等等能力都是很独立的能力，我们现在的模式是用NPM包的模式，迭代成本非常高 。

b. 后续如果百川想用星云的考试能力怎么办？按之前我的想法，只能提供iframe，其实这样的体验是比较差的 。

 【 古金雨 】

对于大会的晚场我没报名参加，感觉还是有点遗憾的，但是我也从论坛中看到当晚的分享内容，特此贴出来分享一下。

Q：优秀前端都有什么特质？

A：像素思维（追求极致的还原度），充满好奇心，能与他人良好合作。善于读书，善于思考，实现自己的认知升级。关注基础知识及API的底层实现，不要做单纯的API Caller~

Q：入行时和现在对前端的认知和思考，有没有发生什么变化？

A：前端始终跟人机交互息息相关，随着终端运算能力的提升，终端设备使用场景越来越复杂，前端对即时性、好玩性以及用户体验要求越来越高。

 Q：带团队以来对个人有什么改变？

玉伯：带团队以来个人的改变其实不是很多，主要是从开源社区中汲取到很多经验。开源天然不是一个人在干活，通过社区运营的大型开源项目，本身就涉及到多人之间的协同。所以就以开源项目的方式运作实体团队，团队成员有问题可以通过类似提issue的方式来沟通解决，同时也像管理大型开源项目一样，非常注重内部交流及高效协同。

 Q：如何始终保持对技术的热爱？

玉伯：技术的力量，是整个社会创新最大的动力之一。始终觉得行业很有意思，每隔一阵又会有很多想不到的惊喜。

响马：觉得跟人打交道比较费劲。写程序本身就是放松的~

Danel：学习新事物，给出问题的解决方案，对事情保持好奇心。

Q：成长的关键点？

Hax：多年前发现 Firefox 中有个 JS 行为与标准不一致，就给 Firefox 提了个 issue，竟然得到Javascript之父亲自回复并认可，非常触动。加入TC39也是很重要的事情（顺带又吐槽了class field hhh~)

玉伯：从上学谈起，到加入淘宝及支付宝，在all in 无线时代的坚守，到最终实现破局，中间有非常多的心路历程。

编辑 | 钱维

-

推荐阅读